Systems and methods for controlling a locking mechanism using a portable electronic device

ABSTRACT

Systems and methods are provided for operating a remotely operable lock. In an example embodiment, a method comprises providing a first web service for receiving credentials or a command from a portable electronic device having a software application installed thereon, issuing a command for receipt by the lock from the web service, and providing an application programming interface at the first web service for integrating a second web service or the software application with the first web service to allow the portable electronic device to communicate with the lock or web service.

RELATED APPLICATIONS

This application claims the benefit under 35 U.S.C. 119(e) to U.S.Provisional Patent Application Ser. No. 61/481,518, inventors Gerhardtet al, entitled “System and Methods for Controlling a Locking Mechanismusing a Portable Electronic Device” filed May 2, 2011, which isincorporated herein by reference in its entirety and made a part hereof.

BACKGROUND

1. Technical Field

The present disclosure relates to access control for security purposes,and more specifically to electronic access control mechanisms which canbe locked or unlocked remotely using commands issued from a website,portable electronic device, or other computer devices through means ofsoftware, Short Message Service (SMS), Remote Frequency Identification(RFID), Near Field Communications (NFC), or other means of radiocommunication. Non-limiting examples of a computer device may includebut are not limited to a laptop Personal Computer (PC), a desktop PC, atablet PC, a smart phone, a mobile phone, or Personal Digital Assistant.

2. Description of Related Art

There are a number of electronic locks which can be activated using cutkeys, scanning a passive Radio Frequency Identification (RFID) tag witha hardwired reader, or pressing a button on an electronic key fob whichtransmits an encrypted radio signal to an access control mechanism.

These devices generally rely on hardware components unique to each user,and which if lost or compromised require system reprogramming andmaterial replacement.

SUMMARY

The present disclosure relates to a network (e.g., Internet) accessiblesystem and web service to communicate with remotely operable locks, forexample radio frequency controlled deadbolt locks, doorknob locks, orelectrical strikes which can be actuated remotely by communicating witha nearby server through encrypted Internet communication protocols. Theservice can be accessed from portable electronic devices with Internetconnections or that are equipped with Short Message Service (SMS)functionality as well as non-portable devices such as Desktop PersonalComputers with network connections. An individual signs up for anaccount on the website associated with the service. The website acts asa gateway service to access, administer, and configure the remotelyaccessible electronic lock system. If a user or administrator is theowner of the lock server unit, they may grant other people virtual keysto access the associated lock. The keys may be temporary or permanent.The keys may be valid during certain hours or days or valid at any time.The keys may grant a guest the ability to invite others or not. Theirfunction may be suspended or reinstated by the owner, user or anadministrator at any time. In an example embodiment, the virtual keysmay be sent to a phone number or email address.

A user may use the web service by executing a software application ontheir portable electronic device, which can lock and unlock the door,invite guests, view access history; the user may also visit a websitewhich offers the same functionality. The user can also lock and unlockthe door sending a text message with a corresponding pin code to apurpose specific telephone number. Text messages are validated with apin code as well as verifying that the source telephone number isassociated with the lock. The user may grant others access or changetheir pin code through text message as well.

The system abstracts access control from physical identifiers such asmaterial keys or unique key-cards to virtual keys, which may be accessedfrom physical electronic devices. As the keys are stored in anelectronic format in a secure web server, a loss of an electronicdevice; which is used to access the key, does not represent a lost key.In addition virtual access can be revoked remotely, or the password usedto access the key can be changed at any time. A lost physical key on theother hand might require that the owners rekey their locks to maintain asecure environment.

In an example embodiment, a web service is a method of communicationbetween two electronic devices over the web (internet).

The W3C defines a “Web service” as “a software system designed tosupport interoperable machine-to-machine interaction over a network”. Ithas an interface described in a machine-processable format (specificallyWeb Services Description Language, known by the acronym WSDL). Othersystems interact with the Web service in a manner prescribed by itsdescription using SOAP (Simple Object Access Protocol) messages,typically conveyed using HTTP (Hypertext Transfer Protocol) with an XML(Extensible Markup Language) serialization in conjunction with otherWeb-related standards.

In this specification, a “user” is anyone interacting with the lockingsystem or web service, including a person operating a portableelectronic device as described herein. The words “user” and “device” (or“portable electronic device”) are in some cases used interchangeably,since the device is carried and operated by the user.

A “locking system” or “lock system” includes a “lock”, and the terms aresometimes used interchangeably. Configuration, description, use orclaims to a “locking system” or “lock system” includes configuration,description, use or claims to a “lock” accordingly.

In an example embodiment, a system for operating a remotely operablelock comprises: a web service for receiving credentials from a portableelectronic device; authenticating the received credentials; and issuinga command for receipt by the lock upon successful authentication of thecredentials. The system may further comprise a tag located on oradjacent the lock and associated with the lock, the tag allowing theportable electronic device to identify or receive credentials from thetag. In an example embodiment, receiving credentials from a portableelectronic device includes receiving a command input by a user on theportable electronic device. The web service may further issue a softwareapplication for installation on the portable electronic device, theapplication allowing communication of credentials or commands from theportable electronic device to the web service. The web service mayfurther to update the application software periodically.

In another example embodiment, a system for operating a remotelyoperable lock comprises: a web service for detecting the proximity of aportable electronic device to the lock; receiving credentials from theportable electronic device; and issuing a command for receipt by thelock. The web service may further authenticate the credentials receivedat the web service, and based on a successful authentication, issue thecommand for receipt by the lock.

The system may further comprise a tag located on or adjacent the lockand associated with the lock, the tag allowing the portable electronicdevice to identify or receive credentials from the tag. Receivingcredentials from a portable electronic device may include receiving acommand input by a user on the portable electronic device.

The web service may further communicate with a software applicationinstalled on the portable electronic device, the application allowingcommunication of credentials or commands from the portable electronicdevice to the web service. The system may detect the proximity of theportable electronic device to the lock and automatically launch thesoftware application.

In another example embodiment, a system for operating a remotelyoperable lock comprises: a first web service for receiving credentialsor a command from a portable electronic device having a softwareapplication installed thereon, and for issuing a command for receipt bythe lock from the web service; the first web service having anapplication programming interface (API) for integrating a second webservice or the software application with the first web service to allowthe portable electronic device to communicate with the lock or webservice.

DESCRIPTION OF THE DRAWINGS

The example embodiments may be better understood, and its numerousfeatures and advantages made apparent to those skilled in the art byreferencing the accompanying drawings and descriptions provided in theDetailed Description. For ease of understanding and simplicity, commonnumbering of elements within the illustrations is employed where anelement is the same in different drawings. In the drawings, which arenot necessarily drawn to scale, like numerals may describe similarcomponents in different views. In some instances, different numerals maydescribe similar components in different views. Like numerals havingdifferent letter suffixes may represent different instances of similarcomponents. The drawings illustrate generally, by way of example, butnot by way of limitation, various embodiments discussed in the presentdocument.

FIG. 1 demonstrates an NFC enabled portable electronic device reading anf tag. The act of reading the tag will trigger an application to launchand actuate a door lock.

FIG. 2 demonstrates a camera enabled portable electronic device readinga Quick Response (QR) code. The act of reading the code will trigger anapplication to launch and actuate a door lock.

FIG. 3 depicts one type of door lock in unlocked and locked positions.

FIG. 4 demonstrates how the user's lock server unit connects to thecloud based service by tunneling through the user's firewall. The serveris also responsible for transmitting “lock” and “unlock” codes to thelock.

FIG. 5 presents an alternate configuration of FIG. 4 where the servercontrols a relay box to actuate an electric strike.

FIG. 6 demonstrates the Portable Electronic Device communicating throughthe Internet to the local server

FIG. 7 is a flow chart depicting the steps of using Near FieldCommunication to lock or unlock a door

FIG. 8 demonstrates the advantages of system by enabling extensivemulti-factor authorization through means of Global Positioning System(GPS) coordinates, Wi-Fi™ network connectivity, Near Field Communicationverification, pin code entry, QR code recognition, and timed entry.

FIG. 9 depicts a second portable electronic device attempting to unlocka door for which it does not have access. In this case, the owner'sdevice is notified with relevant information pertinent to the requestorand presented with an option to unlock the door for the requestor.

FIG. 10 demonstrates how the system can be used through the SimpleMessage Service (SMS).

FIGS. 11-30 are schematic views of locking systems, web services withassociated components and features in accordance with various exampleembodiments.

FIGS. 31-31G are charts showing methods according to example methodembodiments.

FIGS. 32-32G are charts showing methods according to example methodembodiments.

FIGS. 33-33C are charts showing methods according to example methodembodiments.

FIG. 34 is a block diagram of a machine in the example form of acomputer system within which a set of instructions may be executed forcausing the machine to perform any one or more of the methodologiesherein discussed

DETAILED DESCRIPTION

The following is a detailed description of illustrative embodiments ofthe present invention. As these embodiments of the present invention aredescribed with reference to the aforementioned drawings, variousmodifications or adaptations of the methods and or specific structuresdescribed may become apparent to those skilled in the art. All suchmodifications, adaptations, or variations that rely upon the teachingsof the present inventions, and through which these teachings haveadvanced the art, are considered to be within the spirit and scope ofthe present invention. For example, the devices set forth herein havebeen characterized herein as executing remote instructions on physicalmachines described as locks by means of controlling electrical relays orcommunicating over serial, USB, or wireless channels, but it is apparentthat other professional or home automation devices may be accessedthrough these means as well. Hence, these descriptions and drawings arenot to be considered in a limiting sense, as it is understood that thepresent invention is in no way limited to the embodiments illustrated.

The present disclosure relates to a system and service for activatingelectric devices including operable locks remotely from a portableelectronic device. The system is constructed in a very modular way inorder to provide configurable degrees of authentication balanced withefficient and appropriate mechanisms for accessibility. Other systemsare not as configurable, not as secure, or not as accessible.

FIG. 1 demonstrates an NFC enabled portable electronic device (100)reading a passive NFC tag (101). The NFC tag may be encoded in a varietyof standards, including but not limited to ISO/IEC 14443 (both Type Aand Type B), various MIFARE implementations, and FeliCa. The electronicdevice provides inductive power (103) to the NFC tag. The NFC tagresponds with a static Universal Resource Indicator (URI) (104) which isencoded in such a way as to launch a special purpose application on theelectronic device. The URI also contains an identifier string unique toeach tag. The same URI can be encoded in the form of a Quick Response(QR) code onto the surface of the tag. The act of reading the tag willtrigger the device to launch the application, passing the unique stringas a parameter. The application then passes the user id, password hash,and unique identifier string to a cloud service. The cloud servicevalidates the information, and performs an action associated with theunique tag identifier, or based on a command issued by a user as inputon the portable electronic device. The action or command is performed ona lock or lock server associated with the tag identifier to actuate thedoor lock in 102. The server sends a confirmation of the actionperformed to the electronic device.

FIG. 2 demonstrates an alternate embodiment of the process representedin FIG. 1 with camera enabled portable electronic device reading a QuickResponse (QR) code instead of reading the URI through NFC. In this casethe URI mentioned in 104 would be encoded in QR format instead of an NFCdata type. The user launches a QR code reader application, scans the QRcode, the application parses the code as a URI and the application actsaccordingly to actuate the lock using a unique identifier embedded inthe QR code.

FIG. 3 depicts one type of door lock 102 in unlocked 302 and locked(304) positions. The thumbturn (300) is rotated clockwise orcounterclockwise to drive a spindle which will insert or retract thebolt (301) from the door frame. The thumbturn can be actuated remotelyusing encrypted radio transmissions, which are deciphered by a specialpurpose onboard circuit. If the code has been deciphered successfullythe circuit will enable a motor which will drive a gearing system whichrotates the spindle. This type of door lock is commercially availableand represented here for the purpose of illumination and to providecontext to those skilled in the art.

FIG. 4 demonstrates how the user's lock server (403) connects to the webservice (400) by tunneling through the user's firewall (401). The serveris also responsible for transmitting lock and unlock commands (alsotermed “requests” in this disclosure) or codes to the lock.

The web service (400) securely controls all signals routed to the endlock. As such, it will accept commands from authenticated browsers andweb services and relay them to the desired lock assuming allauthentication requirements have been met.

In order to properly relay commands through various Network AddressTranslation (NAT) and firewall mechanisms with minimal initialconfiguration on the part of the user, the web service and lock server(403) engage in Secure Shell (SSH) reverse tunneling. When the lockserver is first connected to an Internet connection it will attempt toinitiate one or multiple Secure Socket Layer connections with the webservice using the SSH implementation. If the lock server cansuccessfully connect to the web service, the web service will initiate areverse tunnel, whereby a forwarding port on the web service is bound toa second port on the lock server. In this manner requests received bythe web server will be forwarded to the lock server without having toactively negotiate in Network Address Translation (NAT). Requests may befurther restricted using firewall rules. The communication protocolsbetween the two servers are well known to those skilled in the art. Byhaving the lock server initiate the tunnel to the web service, the webservice can access the lock server at any time without first having tonegotiate NAT, thus enabling a more consistently reachable service.

The lock server (403) can either be connected directly to a user'sInternet service or more likely through a router or switch that employsNAT and firewall technologies (402). Regardless of whether or not thiscomponent is present in the system, the reverse tunneling (401) willallow for bidirectional communications between the lock server and theweb service.

The lock server (403) maintains a reverse tunnel (401) with the webservice and receives and executes commands to modify the state of thelock. It is connected to the router or Internet service, a wired orwireless Internet connection. Plugged into the lock server is a remotecontrol unit that communicates wirelessly with the lock.

The remote unit (404) is either built directly into the lock server orplugged into the lock server through a connector such as, but notlimited to, USB. Depending on the type of wireless lock, the remote unitwill take a signal and convert it into the appropriate format for thewireless lock. The signal will then be relayed over radio frequency tothe lock and be executed.

In the case of bidirectional radio frequency communications between theremote unit and the lock, it is possible for the lock to confirmreception of the signal by sending a signal back to the remote. It isalso possible that the lock may signal other information back to theremote including current battery status as well as any malfunction thatoccurs on the lock. Along with this, a lock with an associated key padcan relay the key pad command signals to the remote which are in turnpassed through the lock server to web service to authenticate a userwithout a personal electronic device.

FIG. 5 presents an alternate embodiment of the components presented inFIG. 4. Here the lock server is instead connected to a relay controlcircuit (501) through a connector such as USB (500). Commands can besent through the connector to direct the opening and closing of anindividual or multiple relays. The relay control circuit can then beconnected to a buildings electrical strike infrastructure in such amanner that the relay can trigger the release of an electric strike typelock (3402) remotely for a brief, specified period. The release of theelectronic strike on the jamb allows for a door to be opened and anynecessary alarm or security systems to be temporarily disabled.

The relay control circuit can control multiple relays, addressableindividually, so that the lock server can address multiple electricstrikes, or alternatively address other devices, which can be controlledwith an electrical relay in conjunction or isolation such as an alarmsystem, security system, or other electrical appliance.

FIG. 6 demonstrates an electronic device communicating through theInternet to the web service, which passes requests to the local lockserver. The device may communicate to the Internet web service throughany data connection (600) which would provide connectivity, includingbut not limited to Wi-Fi™, 3G, EDGE, SMS and Ethernet.

FIG. 7 is a flow chart depicting the steps of using Near FieldCommunication to lock or unlock a door.

In 700, the user reads a Near Field Communication tag with theirportable electronic device. The NFC tag is encoded with an applicationURI and unique code. Generally a system level interface willautomatically read any sufficiently near tags with system levelprotocols. In some instances the device may first have to be put into aspecial purpose mode before being able to read an NFC tag, in such acase the electronic device would first be placed in a suitable mode toenable the NFC read functionality.

In 701 the electronic device recognizes the URI file type descriptor andlaunches the appropriate application bound to that type of descriptor.In this case the system launches a special purpose lock application andpasses the application the unique id associated with the NFC tag justread.

In 702 the application will notify a web service that it has read a tagand pass along the associated unique id of that NFC tag. The web servicewill authenticate the application in 703 to verify that the read requestcame from a valid, signed in account. If the request is deemed to beinvalid, the application will be notified in 709. If however the requestis valid, the web server will pass a request corresponding to the NFCtag id to a lock server that corresponds to the NFC tag id in 704. Therequest could be a lock request, a timed unlock request, or a togglerequest (issue the opposite request as previously sent.) The lock servercould correspond to one door lock or many.

In 705 the lock server will receive the request issued in 704 and willinitiate the request. If lock server is unreachable (if for instance,the server does not have a power connection) the web server will notifythe application that the request could not be performed in 709. If thelock server is reachable, it will parse the request. If the request wasfor instance to lock a certain door, the lock server will issue acommand to the hardware device associated with that door (404) toinitiate a lock or unlock request 706 with the 102 lock. In 707 the 102lock would actuate. If the lock actuated successfully, the lock serverwould notify the web server which would notify the lock application in708.

FIG. 8 demonstrates the advantages of system by enabling extensivemulti-factor authorization through means of Global Positioning System(GPS) coordinates, Wi-Fi™ network connectivity, Near Field Communicationverification, pin code entry, QR code recognition, and timed entry.

A user with a smart phone or portable electronic device (100) canauthenticate through a combination of individual authentication methods.

A user must be authenticated on a web service (800) in order tomanipulate the lock, as reflected by a cookie that is stored on theuser's browser. The web service in turn can request the state of theuser's session from the cookie and look up associated information withthat user. This session state can then be relayed to the user,indicating whether or not they need to present appropriate credentialsthrough the browser in order to manipulate the lock.

If requested by a lock owner or administrator, an additional form ofauthentication would be a pin code (801) that would be entered on thephone before every action to manipulate the lock. If the pin codematches a pin code pre-designated by the user, then the user would beauthenticated either for a single action or for a set period of time(i.e. five minutes during which any action against the lock may beexecuted).

Any actions by an authenticated user will be relayed to a local lock webserver (802) near the door (on the secured side) that will in turntrigger either a remote control that wirelessly transmits commands tothe door lock or an electrical relay that is directly wired into thedoor lock or strike of the door.

A passive NFC or RFID (Radio-frequency identification) tag (808) can beaffixed next to the door as a method to request access to the door. Sucha passive tag would still require the user's NFC or RFID capableelectronic device to be authenticated to the web service. Alternatively,the NFC or RFID unit noted (808) can in fact be an active reader orwriter module that is wired into a server behind the secure perimeter ofthe door. In this case, the electronic device would transmit anencrypted key via NFC or RFID which would in turn be relayed to theserver and compared against other noted forms of authentication such asan authenticated session on the user's electronic device to permitaccess to the door.

An additional form of authentication is through geo-positioning (804) onthe electronic device as established by GPS or similar satellitetriangulation (809) on the electronic device. Latitude and longitudedata would be relayed to the web service which in turn would compare thedata against pre-designated latitude and longitude points that areassigned to the lock. If these points match within a pre-designatederror (i.e. 50 feet within pre-established coordinates), then the useris assumed to be authenticated to the lock, assuming other prerequisiteforms of authentication are confirmed as well.

If the user's electronic device is connected to or detects the SSID(Service Set Identifier) of a wireless (“Wi-Fi™”) network (805) in thevicinity of the lock, this can act as an additional form ofauthentication by establishing that the user is within a given distancefrom the lock. Moreover, the user's electronic device may connectdirectly to the server (802), bypassing any web services in cases wherethey are unavailable, thus allowing for authentication in “offline”situations.

An additional form of authentication would be to request the user tophotograph (806) either a static or dynamic QR code (808) next to thedoor through their electronic device. Such a QR code could be printed ontop of a passive or active NFC or RFID tag or reader, or it could beshown on a display. In the case of a static QR code, the door lock wouldbe identified and a command would be carried against the lock assumingthat the user is also authenticated by another method such as a sessionwith the web service. In the case of a dynamic QR code, the code couldrotate to a unique code at a pre-designated interval, thus confirmingthe time at which the user took the photo as well as their presence bythe specific QR code display and as such acting as a form ofauthentication.

Depending on the combination of authentication methods required by alock administrator, the door (807) would enable the end user to carryout manipulations depending on the success of those authenticationattempts. A non-limiting example of this would be the requirement thatthe user confirms their location through geo-location (804), isauthenticated by a cookie through a web service accessed by their phone(800) and successfully enters a pin code that they have pre-designated(801).

FIG. 9 demonstrates a scenario where someone who is not authorized as auser on a lock requests access. The unauthorized account on theelectronic device (900) attempts to read the NFC/QR code (101) using themethods described previously (103 & 104). The device will attempt toauthenticate with the web service, however as the device is notauthorized the web service will not unlock the door. The application onthe device (901) receives a response from the web service indicating theuser does not have access to that lock instance and will prompt theunauthorized user if he or she wishes to request access from the lock'sadministrator. If the user of 900 selects “YES”, then the lock'sadministrator will receive an access request on their electronic device(100). The administrator may be prompted with the requesting user'sprofile information optionally including but not limited to name, photo,email address, or agency of employment. The administrator may unlock thedoor remotely and optionally add the requester as an authorized user ordeny the requestor access.

FIG. 9 additionally depicts how the service may be used analogously to adoorbell. Upon a guest scanning a tag (101) the owner is notified (902)that said guest is requesting access. This is similar how a guest wouldnormally request entrance to a property by ringing a doorbell, whichwould notify the owner that the guest is at the door. With this servicehowever, the owner could be notified from anywhere where they have adata connection to their electronic device. An added benefit is theowner can unlock the door remotely and log the time which the guestrequested access through the service.

FIG. 10 demonstrates how the system can be used through the SimpleMessage Service (SMS) or text message service.

An invited user sends a text message with a pin code (1001) that theyhave either pre-selected or that has been pre-assigned to them to apre-designated phone number. Along with this pin code, the user sends acommand to the web service to change the state of the lock, such as thecommand to unlock.

The cell phone provider receives the text message (1000) and relays itscontents to the web service along with the phone number of the user'sphone (100). The web service verifies the users phone number along withthe given pin code to authenticate the user for the single action thatthey wish to carry out against the lock.

If the web service successfully authenticated the user and interpretstheir command, then it relays the signal to the electronic door lock(102), which carries out the appropriate command such as locking orunlocking.

FIG. 11 depicts a wireless key device or fob (1102) containing a unique,identifying, digital signature that may come in the form ofcryptographic public/private key pair, private/private key pair, uniqueserial number, unique Media Access Control (MAC) address or equivalentpermutation. A web service (1100) stores one or more elements of thisunique signature (public key, one half of a private/private key pair,serial number) along with data indicating which signatures have accessto which locking systems (1101). The web service (1100) relaysauthenticated signatures to the appropriate locking system (1101) eitherdirectly or through indirect means such as a mobile phone, electronicbase station, or other communication methods between web service andlocking system described elsewhere in the patent body.

When a wireless key device (1102) issues a command to the locking system(1101), the locking system first checks to see if the wireless keydevice's signature is authorized to issue the corresponding command bylooking up the unique signature associated with the device (1102) in alocal memory store, or by attempting to communicate with the web servicebefore processing the request. Commands may be restricted to finerlevels of granularity such as date, time, schedule, proximity, wirelesssignal strength, or other attributes that are communicated between keydevice, locking system and/or web service (1100). All commands issued bythe wireless key device (1102) may be logged and stored on the lockingsystem and/or relayed to the web service. Commands and devices whichhave not been authorized to use the lock system will not be executed butthe issuance of these commands may be relayed to other authorizedelectronic devices through the web service so lock system administratorsare aware a wireless key device which has not been authorized to use thelock system is attempting to use the lock system. Administrators mayrespond by granting authorization to the wireless key device (1102)dynamically.

In addition to communicating directly with the locking system, wirelesskey devices may communicate with intermediary devices which maycommunicate directly with the locking system (1101), web service (1100),or each other to provide equivalent functionality, to boost range,provide enhanced proximity detection, provide alternative commandissuance, or relay additional information concerning the locking systemstate, device presence, or ambient data.

FIG. 12 depicts a mobile device (1200) device containing both low andhigh powered radios that communicate through cellular, wired, orwireless internet protocols to securely relay data between a web service(1201) and a locking system (1202).

In an example embodiment, the web service (1201) establishes anencrypted communications system using codes, encryptions or secretsknown only to the web service and locking system (1202) and chooses toroute these communications through a mobile device (1200). The messagesmay contain unencrypted routing information, encrypted routinginformation which only the mobile device may decrypt and encrypted datawhich only the locking system may decrypt. The mobile device (1200) maynot be able to inspect the data transmitted to the locking system fromthe web service (1201) due to its encryption but may still pass alongthe data to the appropriate locking system (1202) using additionalrouting information transmitted to the mobile device. The encrypted datatransmitted to the locking system (1202) may contain commands to lock,unlock or otherwise activate the locking system, read the lockingsystems status including battery life, authenticate the mobile deviceonto the lock, authenticating other devices onto the locking system,update the locking system firmware, or read access log data. The datatransmitted to the mobile device (1200) may contain routing information,including but not limited to unique signature data associated with thelocking system (1202) and web service (1201).

In an example embodiment, the mobile device (1200) uses its wired orhigh-powered radios to communicate to the web service (1201) while usingits low powered radios to communicate with the locking system (1202).Both high powered and low powered communication channels may haveadditional encryption decipherable by a combination of the initiating,intermediary, and/or terminal devices.

In the example embodiment depicted in FIG. 13, when a user approachesthe lock system (1300), they trigger an infrared, sound, radio orvibration sensor. The sensor consumes significantly less power that theradio transmission device required to communicate with a web service(1301) over protocols that may include but are not limited toTCP(Transmission Control Protocol)/IP (Internet Protocol)/UDP (UserDatagram Protocol), HTTP (Hypertext Transfer Protocol), HTTPS (HypertextTransfer Protocol Secure) and SSH (Secure Shell). This in turn willnearly instantly wake up the higher power consuming components of thesystem (1300) not already in use by the sensor.

Once the locking system (1300) is awake and in a state where it mayreceive commands, it may either request status change commands from theweb service (1301) or process queued commands from the web servicedirected at itself, such as Short Message Service commands sent to theweb service to be relayed to the locking system.

Higher powered radio devices in a portable electronic device (1302)requesting status information from the web service (1301) will receiveupdated locking system status at this point. Alternatively, the highpowered radio device may search for other compatible radio deviceswithin range.

The proximate user may send a lock, unlock or status request commandeither directly to the now radio-enabled lock system (1300) directly, orroute requests through the web service (1301) which in turn relayscommands to the lock system. This significantly extends the battery lifeof the locking system (1300) as well as preserves bandwidth.

In FIG. 14 a mobile device (1400) may include a number of radios,notably those related for long distance communications such as cellularor satellite. It may send commands to or request the status of a lockingsystem (1401) remotely through its cellular or satellite connection to aweb service that in turn relays the commands or requests through anothercellular or satellite connection (1402) to the locking system.

The locking system (1401) runs a high-powered radio connectionintermittently so as to extend the life of any electricity storagedevices, potentially several orders of magnitude depending on energysaving techniques used. The high-powered radio connection may includebut is not limited to cellular or satellite communications. The methodby which the locking system (1401) activates the high-powered radioconnection to send status and request commands may include detection ofproximity of another powered radio such as those contained in mobiledevices.

In an example embodiment depicted in FIG. 15, the locking system (1500)may register a knocking or door closing event through the addition of avibration sensor. This data may be used to “wake” the lock from a lowpower state to a higher powered state whereby it would communicate witha web service (1501) or mobile device (13402) directly in order toindicate the knock or vibration. The sensor may be tuned so as todistinguish between the types of repetitive motion that would indicate aknock as opposed to the door closing or opening.

The web service (1501) may relay the data through any range of datainterfaces to mobile devices to indicate the presence of someone at thedoor, a lock operation or a door close or open event. The web servicemay also use the opportunity of a higher-powered state device to relayinformation back to the device such as previous lock or unlock commandsissued locally as well as receive lock status information from the locksystem (1500).

A mobile device (13402) or web service (1501) may receive data about theknock sequence, lock operation or door close or door open eventnotifying the user. If the person knocking on the door is known, thenotification might also contain data about who is knocking on the doorsuch as unique signature data like MAC addresses associated with mobiledevices attached to persons knocking at the door or a unique knocksequence.

This disclosure includes various ways to detect whether or not a user isproximate to a locking system. In various example embodiments, this mayinclude detection of a locking or unlocking operation, an alarm, or thepresence of an internet-connected device, and may further includegranting appropriate access to a user for that locking system. The broadobjectives of the proximity-based features of the locking system includedetecting a person and/or granting them access to control some resource,whether an electronic lock, internet connected tea kettle, for example,or some other device, or taking control of a device, or identifying theuser of a device. Reference to “locking system” is intended to includesuch devices.

FIG. 16 depicts a (locking system) (1601) which detects the presence ofa user through a number of methods. A user may be granted the ability toissue a range of commands on the locking system (1601) using a webservice issuing remote commands to the locking system, or for example aninternal data store on the locking system which notes whether or not theuser is appropriately authenticated.

The authenticated user's commands that they may send while present maybe constrained, including the specific commands that may be sent, thedata that may be requested from the system as well potential constraintsbased on time and schedule. The locking system (1601) may detect thepresence of a user or person which relays the fact of this presenceeither directly or indirectly through a locking system web service(1602) to an authenticated user with appropriate access via a portableelectronic device (1603) on the locking system, such as anadministrator.

Detection of the user may be made through specific radio technology on amobile device or electronic credential (1600) that may communicatedirectly with the locking system (1601) or may be detected passively bythe locking system (1601) on the user's approach. Depending on whetheror not the user is approaching the locking system or moving away fromit, the system may send differing notifications to the locking systemweb service (1602) and, in an example embodiment, directly or indirectlyto interested authenticated users. The locking system (1601) may alsoautomatically trigger different commands depending on whether or not theuser is detected to be approaching or moving away from the lockingsystem such as unlocking or disarming on approach or locking and armingon moving away. Similarly the concept of granting access to the userbased on their electronic credential or mobile device (1600) may beextended to any appropriately enabled device such as but not limited toappliances, vehicles, electronics, industrial systems, security systems,access control systems, computers and other devices.

The approaching user device or credential (1600) may be notified of anycommands for which they have access to on the device if they are soauthenticated. The presence of a person may also be detected through theuse of technology including but not limited to passive or activeinfrared sensors, radio signature detection, motion on cameras, specificsounds on microphones, light sensors, accelerometers as well as anyappropriate form of motion detection. Depending on the sophistication ofany of these sensors as well as the presence of an electroniccredential, authenticated users may be alerted of a specific person'spresence similar to the fashion described above.

A mobile device (1600) that enters the proximity of thepresence-detecting locking system (1601) may receive a notification asto the ability to request access to the system from that that device soas to send and receive commands to and from the device. If the user isgranted access to the device via the locking system web service (1602),then they may immediately send and receive commands to and from thedevice.

Depending on the radio communication protocol used to detect presence bythe locking system (1601) of the mobile device (1600), a “pairing”process may be required to ensure secure, encrypted communication. Whilethe chosen radio standard may offer a variety of closed pairing methods,open pairing methods may still securely be used to pair mobile deviceswith the locking system despite the absence of physical contact betweenthe mobile device and the locking system. An open pairing system mayallow for all mobile devices approaching the system with the appropriatemobile applications and radios to pair with the system, however,preclude the ability to send and receive any commands to the systembeyond the initial pairing dependent on a pre-shared signature with thelocking system and the mobile device. A web service (1602) to which thelocking system connects may revoke or issue these keys.

Alternatively, a knock or series of knocks on a closed pairing systemmay trigger a secure pairing between a present device (1600) and thelocking system (1601) despite the fact that the device may be held by auser outside a secured perimeter and even if the locking system isengaged. If available on the locking system, a key pad and pin entry mayalso be used to complete pairing between the mobile device (1600) andthe locking system (1601).

FIG. 17 depicts a motion detection system or radio detection lockingsystem detecting a person (1701) through their mobile device (1703),electronic credential or infrared signature (1702) detecting body heat.

The detector (1702) in turn relays information of the detection event,including if available information about the person as garnered fromtheir mobile device or electronic credential, to the web service (1704).This information may be used by the web service for a number of purposesincluding but not limited to triggering a locking system, arming ordisarming an alarm system for appropriate users or notifying athird-party application or service so that it may carry out an action.

If the detector (1702) picks up the radio signal of an authenticatedelectronic credential or mobile device (1703), it may send a differentsignal than the signal sent from the detection of person through theirinfrared signature. This may allow for seamlessly disabling alarmsystems for authenticated users while triggering them for unknowninfrared signatures.

Restrictions on authenticated users as well as the authentication of newusers may be dictated by the web service (1704) that is in communicationover the internet with the detector. Specific motions interpreted bysophisticated detectors such as passive infrared sensors or cameras mayalso serve to authenticate users.

FIG. 18 depicts the presence of a mobile device (1800) to a lockingsystem (1802) as detected through global positioning satellites (1801)or other similar technologies that rely on triangulating a mobile devicethrough the use of other known radio signals.

In turn the mobile device (1800) may automatically select the closestlocking system (1802) available so that the user may instantly sendcommands to that locking system upon activating the mobile device and,potentially, an application dedicated to controlling the locking system(1802) on the mobile device (1800).

The mobile device (1800) may store information as to how it selects thelocking system (1802) based on a variety of methods. The mobile devicemay receive the coordinates of the locking system upon enrollment of themobile device or the authentication of an authenticated user of themobile device. The coordinates may be determined by the locking deviceitself through a number of means, including but not limited to GPS,Wi-Fi™, cellular signals or IP address lookup. Alternatively, theassociated locking system (1802) on the mobile device (1800) may requestthe user to manually input a trigger location for the application. Thistrigger may occur the first time that a command is sent to the lockingsystem such as during its initial registration or after a certain numberof commands have been detected to have been sent from a specificlocation. Location trigger coordinates may be stored locally on themobile device as well as additionally sent to an associated lockingsystem web service that in turn relays the data to other authenticatedclients so they may avoid any initial set up.

The authenticated user may be limited in their ability to send commandsto the locking system based on their detected location for securitypurposes. Administrators of the locking system may wish to limitcommands to the locking system to a certain proximity at which a user isdetermined to be present to the locking system, incorporating some or nomargins of error depending on the ability to pin-point the mobile devicecoordinates and the confidence in those coordinates. Multiple locationfactors may be used to achieve more accurate location information.

Depending on the preferences of locking system administrators, somelocking systems may be public to all users executing the appropriatemobile application within a certain proximity range of the lockingsystem. This allows users to request access through the locking systemweb service to send or receive commands from the locking system.

The locking system may use the ability to establish bidirectionalcommunications between itself and a mobile device as another proxy forthe presence of a user. A locking system may have the constraints setdynamically on certain users that their authenticated mobile device mustbe connected to a specific Wi-Fi™ network so as to execute lockingcommands. The connection through a technology such as Wi-Fi™ may bedirect to the locking system, through a shared internal network orthrough a different network that has been pre-established on the lockingsystem.

FIG. 19 depicts a locking system (1901) that is triggered by a mobiledevice (1900) which has entered the proximity of the locking system.Proximity to the locking system of the mobile device may be determinedby a number of methods as described above.

On a mobile device (1900) having the ability to execute applicationswithout the user's explicit intervention, it may be possible to sendnotifications from the lower level operating system to the attention ofthe user on the approach of a pre-defined “geo-fence”. In an exampleembodiment, a geo-fence is a virtual perimeter for a real-worldgeographic area. A geo-fence could be dynamically generated, as in aradius around a store or point location. Or a geo-fence can be apredefined set of boundaries, like access-restricted zones or propertyboundaries. User-defined geo-fences may also be in use. When thelocation-aware device of a location-based service (LBS) user enters orexits a geo-fence, the device may receive a generated notification whichmay be used to launch a special purpose application to operate the locksystem or otherwise generate an event. The lower level operating systemmay designate the geo-fence or it may relay the necessary data of thegeo-fence to a specified locking system mobile application. Depending onthe lower level operating system, the locking system mobile applicationmay or may not have the ability to automatically send a radio requestdirectly to the locking system or to a web service associated with thelocking system to trigger a command.

In the case where the lower level operating system hinders or precludesthe ability of the mobile application to send a radio command, anotification of proximity to the locking system may be relayed to theuser. In turn, acknowledgement of this notification through apre-designated action by the system such as a swipe may be used tolaunch the locking system mobile application and trigger a specificcommand. Depending on the lower level operating system and userpreferences, a pin code or other authentication action may need to betaken to carry out the command after a gesture or command is made on themobile device.

If the user is appropriately authenticated and has appropriate access tocarry out commands on the lock, then their command may be immediatelycarried out upon launch of the mobile application from anotification-triggered action due to the fact that the lower leveloperating system allows access to send radio commands either directly orindirectly to the locking system.

The same premise may be used to arm or disarm alarm systems. Triggersfor different commands such as lock or unlock or arm or disarm may besent to the locking system depending on whether or not the user isdetected to be moving towards or away from the locking system. Theinformation as to whether or not the mobile device leaves or enters thegeo-fence may be handled by the lower level operating system. Themessage relayed to the user of the mobile device in the form of anotification may be dynamic depending on direction of the user towardsor away from the locking system as well as the user's last knownauthentication and access states.

The locking system mobile application may immediately carry out acommand upon being loaded by the user from the notification. The usermay be directed to a dashboard where they may send or receive othercommands to or from the system.

Proximity to the locking system by appropriately enabled third-partydevices or electronic credentials may also be registered in the samefashion as described above. These third-party devices may include butare not limited to radio-enabled phones, computers, watches, tablets,personal digital assistants and other electronic credentials. They wouldconvey the presence of known or unknown users proximate to the lockingsystem and would potentially be authenticated in the same way as amobile device to send commands to the locking system. Authentication ofa third-party device may originate from the locking system web service.

Although the primary operation of the locking system may be in relationto an internet connection so that it may interact with a web servicethat authenticates and revokes access to appropriate users, it may alsofunction in an offline function whereby it communicates directly with anelectronic credential or mobile device.

In the case of offline operation, a proximate mobile device orelectronic credential would be authenticated directly on logic directlywithin the locking system, not merely on an associated web service. Ifdisconnected from the web service the locking system would still be ableto authenticate and accept commands from authenticated users (theirmobile devices and electronic credentials). Schedules, time limits andother restrictions not reliant on a live connection to the web servicewould also still be adhered to by the locking system.

The present disclosure includes systems and methods for allowing thirdparty systems to access a locking system, send and receive commands. Thethird-party system will typically need to be authenticated by a userwith sufficient powers (i.e. administrator, owner) to authenticate thethird party system. That authentication may be revoked or restricted atany time. Additionally, access may be granted directly to third-partydevices which may connect directly to the locking system to control it.This facility extends to security/alarm systems as well.

FIG. 20 discloses a third party service which has triggered a request toaccess the resources available on the locking (or security/detection)system (2004). The request from the third party (or requesting) system(2000) may be sent from third party software, originating eitherdirectly or indirectly from the third party web service. The requestwill typically contain information about the locking system (2004) or anassociated user granted access on that system sufficient to directly orindirectly instruct the granting web service (2001) of the access thethird party requires. An indirect request from the requesting webservice may originate from web or mobile application (2003) that ishosted by the third party service, or another application which in turnhas been granted authentication to make such requests.

In an example embodiment, the request from a third party system toaccess the resources and in turn control the locking system (2004)requires approval from an authenticated user (2002) who has been grantedappropriate permissions on the locking system. The locking system webservice (2001) may enumerate available commands dependent on theauthentication of the requesting user. If appropriate authentication ismet in order to grant the third party system access to the system thenthis access may be constrained or unlimited in scope, not limited to butincluding constraints such as time of request, quantity of requests,frequency of requests, format of request and commands available to berequested.

Once authentication is established for the third party system, a user ofthe third party system who in turn has sufficient authentication mayseamlessly send and receive data from the locking system such as lock orunlock commands and locking system requests.

The locking system web service may interact through a standardized setof commands with the third party system to additionally notify it, andin turn, the user's third-party clients, with information about thestatus of the locking system not limited to but including suchinformation as revocations in access, offline alerts, door status andbattery levels.

Previously authenticated third-party services may have their accessrevoked on a number of factors, namely those relating to cancellation oftheir access by an authenticated user or abuse of the system such assending an excessive number of commands or attempting to falsifycommands. Third party services may be identified by a number of factorsincluding but not limited to application keys, IP addresses, MACaddresses and user agent strings.

FIG. 21 demonstrates an alternate example embodiment whereby anelectronic credential or wireless remote (2102) is pre-authenticated tosend and receive commands from a locking system (2104). The lockingsystem web service and third party web service (shown together at 2101)communicate with the client third-party applications (2103) receivingand sending commands to pre-authenticate the electronic credential.“Pre-authenticate” is the process of instructing the locking system toexecute commands sent from an offline electronic credential based on aunique identifier or rolling token that is specific to that offlineelectronic credential.

The third-party client application may automatically request access onbehalf of the electronic credential based on the trigger of an outsideevent such as booking a room for use at a certain time (see screen in2103). The electronic credential may be entirely disconnected andoffline from the locking and third-party web services, however, it wouldstill be able to issue authenticated commands to the locking system(2104) if the system has been informed of the electronic credential'sunique identifier. The electronic identifier may trigger an action withthe locking system either through direct input by the user or throughindirect input such as coming into proximity with the system, whereproximity is the greatest range at which the electronic credential maycommunicate successfully with the locking system.

An electronic credential may include but is not limited to a simple keyfob style remote control or a mobile phone that carries on it the sameunique radio signature. The same features such as detection at proximityto carry out commands or direct commands from the user would apply. Inaddition, an internet connected device emulating a simple offlineelectronic credential may also relay additional data to or from thelocking system.

FIG. 22 discloses another example embodiment whereby a newlyauthenticated user (2201) receives a message confirming theirregistration via a communication such as but not limited to a textmessage, an email, a push notification or a third-party applicationnotification informing the user of a pin code that allows the useraccess to a locking system (2204). If entered properly on a keypad (notshown) on the locking system, the pin code may grant access to a numberof functions, including but not limited to locking or unlocking thelocking system (2204). In the case where a third party application(2202) has already been authorized to send communications to the lockingsystem (2204), clients to the third-party system may handle allcommunication to end users in order to convey information about the locksystem as well as the ability to send commands through to it. A pushnotification may be context dependent, but in an example embodiment theweb service sends a push notification to the portable electronic deviceinforming the device that the status of the locking system has changed.It is also conceivable that the locking system sends a push notificationwhen the status of the locking system has changed (for instance someonemanually unlocked the door with a key). In an example embodiment, theportable electronic device sends the web service a push notificationwhen a user is added as an authorized user to a lock.

Depending on the authentication conveyed to the third party service, thepin code may be relayed from the locking system service to thethird-party service so that it may be conveyed to the end user. The pincode may be configured in a number fashions. The user may be required toenter a user specific pin code along with by a lock system specific pincode. Alternatively, the user may be granted a unique pin code for eachlock system, where uniqueness is determined by requirements of thelength of the pin code in terms of the total key space of pin codes.

Each time a granted user (2201) enters the pin code into a lockingsystem where they have been granted access (2204), the entry of the pincode and any commands sent may be relayed by web service (2202) to thelocking system (2204). If the issuing user (2203) directly or indirectlyremoves the granted user (2201) from the locking system or carries outan action that would remove the granted user from the locking systemthrough the third-party service, the granted user's pin will beinvalidated. An example of this includes the cancellation of a granteduser's booking of a space for a specified time.

FIG. 23 depicts a dashboard component that may be shown by a third-partybooking service which is authenticated to act on behalf of asufficiently authenticated user on the locking system. In this scenario,a potential guest (2300) requests to book a space from the host bookingout the space (2301). The third-party system may allow for internalmessaging (2302) between potential guests and hosts. Upon the agreementof a booking time, the third-party system may automatically requestaccess from the locking system for the guest, issuing the guest accessto control the locking system for the time specified by the booking.

The third-party system may automatically message the guest theinformation required to access the locking system. Depending on thelocking system, this may include a pin code (as shown in 2301) or a linkthat allows for setting up the locking system on a mobile application.Alternatively, the third-party system may request the locking system toauthenticate an electronic credential to access the system similar tothe process described above.

The third-party system may incorporate locking system controls directlyinto its dashboard component (2303) which allows the guest to modifytheir unique pin code (if granted) or to send locking system commandsduring the period of time and on the schedule which they have permitted.

Third party devices may interact directly with the locking system ifthey have been granted an appropriate unique identifier. The third-partydevice communicates directly with the locking system to send thecommand. The third-party device will typically first bepre-authenticated to send commands to the locking system in the samefashion as described above. This may mean that a unique identifier inthe locking system or locking system web service is used to enableaccess to the for the third party device.

When the unique identifier is either relayed to the locking system, aderived rolling token is relayed or the device detected via an encryptedproximity signal from the third-party device, the locking system istriggered. The ability for the third-party device to send commands tothe locking system may be constrained or limited by various schedule andtiming constraints. The third-party device's authentication to use thelocking system may be revoked or re-enabled at any time dependent oncommands send to the locking system from the locking system web serviceor a third-party web service.

In using any third-party service or device to communicate with thelocking system and locking system web service (if so configured),security is of the utmost consideration. The communication channelsbetween the locking system web service and third-party web service maybe required to be in an encrypted form, including but not limited tostandards such as SSL, SSH, AES or other public or proprietaryencryptions schemes.

Similarly, direct communications between the locking system andelectronic credentials or third-party devices may be encrypted throughvarious standards such as those incorporated by technologies includingBluetooth™ Bluetooth™ Low Energy, Near Field Communications, MiFare™,Felica™ (Felicity Card), Wi-Fi™, WEP (Wired Equivalent Privacy), WPA(Wi-Fi™ Protected Access), WPA PSK (Pre-shared key), and others. MiFareis the NXP Semiconductors-owned trademark of a series of chips widelyused in contactless smart cards and proximity cards. Custom encryptionstandards may optionally be used in place of other encryptiontechnologies or may be layered upon those technologies for additionalsecurity.

FIG. 24 depicts a web service dashboard (2400) which conveys the abilityfor administrative users to send and receive commands from a lockingsystem, as well as invite other users to the system (2403), view anycached or live data about the locking system or its state and identifycurrent users on the system (2402) as well as their activities on thelocking system. This dashboard may be available in a variety of formatsscaled for different applications including but not limited to atraditional desktop browser interface, a mobile phone interface, tabletphone interface or third-party interface. Depending on the privilegesgranted to the user viewing the dashboard, different information may beconveyed to the user. For instance, certain users may have variations onthe ability to create, modify, manage and revoke access for other usersas well as the ability to view logging information.

The web service dashboard (2400) may allow for the entry of additionalidentifying information for the user that may be used as anauthentication token either in the form of a pin code that is entereddirectly in the door, a pin code that is used for text messaging apre-designated phone number to send commands to the door, a pin codethat is used for either purpose or any other serial number or secrettoken information that relates to an offline electronic credential suchas a key card or key fob.

Information about other users (where user is a proxy for person on thesystem) (2402) may include identifiers such as but not limited to photosof the person, the person's names, aliases, email addresses, phonenumbers, status on the web service, status on the locking system,associated privileges. The ability to issue, modify or revoke a virtualcredential to other users may also be shown and managed through thissystem.

New virtual credentials may be issued (2403) by a variety ofcommunication protocols including but not limited to email, phone call,text messaging, application interfaces or third party messaging. Thesecredentials may be granted for various scopes of time and location, notlimited to but including time schedules, start and expiration times,specific locations as determined by geo-data, specific locations asdetermined by proximity through powered or unpowered radio, single ormultiple usages and may require multiple types of authentication to beused by the person to whom they are granted. The field in which thevirtual credential is entered may automatically populate withidentifiers such as but not limited to names, emails, photos, aliasesand or phone numbers of users already registered to the system orassociated from another third party system as the inviting user types inthe field and letters are matched with the identifier dynamically. Thefield may optionally be extended to enter multiple identifiers forvarious people so as to invite multiple users at the same time with thesame type of credential or optionally varying types of credentialdepending on a requested algorithm, i.e. incrementing or decrementing.

FIG. 25 discloses a logging panel as viewed by an authenticated userthrough a web, mobile, tablet or other browser interface. The webservice associated with the locking system may record a range ofinformation including that relating to information sent and received toand from the locking system as well as physical changes to the lockingsystem, non-authenticated users attempting to access the locking system,events specific to the web service itself or third-party web servicesrelating to or authenticated on the web service or locking system.

Actions carried out by users may be conveyed along with information(2500) such as but not limited to names, aliases, date and time ofaccess, whether or not the virtual key was valid at the time the attemptto access the locking system was made, the desired action, proximity tothe location, network location and type, geo location information,outcome and the method used whether the virtual key is from a mobiledevice, radio token, key pad, web interface, application interface or3rd party application.

Any data relating to the locking system that is recorded by the lockingsystem or associated web service or both may be conveyed on a map (2501)which may note the position of the locking system or the position of anydata transmission sent or received from the locking system or webservice. This may indicate whether or not a user was proximate to alocking system at the time they sent a command to the locking system. Ifthe authenticated user has appropriate access to multiple lockingsystems, their coordinates may all be indicated on a single map.

The web service may convey graphs (23402) that indicate the frequency oflocking events over time on a specific locking system. The user may havethe ability to filter these events including but not limited toindividual user actions over time, specific types of actions over time(i.e. number of unlock events on May 1st, 2011), comparing to types oflog entries over time (i.e. number of lock events from a mobile devicevs. number of lock events from the locking system key pad from Apr. 1st,2011 12:00 pm to May 1st 1:00 pm).

The recorded events may include geo-location coordinate informationabout the origin of the command at the time the command was sent by auser. This information may be inferred either directly from geo-locationcoordinate information (2503) encoded directly in the request orindirectly by IP address lookup techniques. Mobile clients, web clients,third-party clients, fixed key pads and readers may be required to sendgeo-location information to the web service in order to successfullyexecute commands.

FIG. 26 discloses an example embodiment allowing the initial set up of alocking system to be simplified so that a new user may quickly connectthe locking system to a corresponding web service or pair the lockingsystem with their compatible electronic device (such as a mobile device,tablet device, laptop computer, desktop computer, personal digitalassistant or third-party device) directly.

An application corresponding to the locking system is used on the mobiledevice (2600) which communicates with both the associated web service(2602) as well as the locking system (2601) so that it may confer theinitial pairing between the new user and the locking system. Thisinitial pairing may request certain identifying information from the newuser in order to authenticate them on the locking system such as but notlimited to their names, aliases, email addresses, phone numbers andphoto. Other identifying information that automatically be sent to theweb service during the initial registration may include but is notlimited to geo-location information, IP address information, cellularnetwork information if available and information about the mobile deviceupon which the application is running.

The locking system may be connected directly through a wired connection(2601) to the mobile device (2600) through a common interface such as anaudio or serial bus connection. The locking system will receiveprogramming commands from the mobile device, including but not limitedto instructions on how to connect to a web service, as well as anynecessary authentication keys to connect to local or wide array networksor to create a pairing with the mobile device itself.

The completion of the pairing process may preclude other mobile devicesfrom carry out the same pairing process, as either dictated by logicdirectly on the locking system or on the associated web service. Theinitial user may allow requests by other mobile devices to pair with thelocking system and these requests may be logged or facilitated by theweb service. Physical interfaces on the locking system such as key pads,buttons and other sensors may be used to reset the locking system sothat it may be associated freely with mobile devices. These interfacesmay require the entry of a specific code or pattern of binary inputs inorder to reset the device to a new pairing mode. Information about anyreset event may be conveyed to the associated web service first and maytrigger notifications or other events on the web service.

FIG. 27 discloses in an example embodiment a direct connection between amobile device (2701) and locking system (2702) which may include bothsend and receive capabilities so that applications running on bothdevices may convey a range of programming, status and commandinformation. This connection may be manifested as an audio, sound ormicrophone jack of varying dimensions such as those common on mobiledevices. The connection may be used for the purpose of the initial setup and pairing of the locking system with available mobile devices andnetworks, programming the locking system, resetting the locking system,sending commands to the locking system as well as receiving status fromthe locking system. These may include instructions for an initialsecured connection to wireless network, whether WAN (Wide Area Network),LAN (Local Area Network) or ad-hoc. The data may be transmitted in anencrypted or unencrypted fashion.

After the initial connection or programming event with the lockingsystem it may bind itself to the mobile device via unique identifiers sothat no other device may access the same programming functionalityunless permission is first explicitly granted by an application eitheron the original programming mobile device or web service.

FIG. 28 discloses a locking system which is limited either by the amountof current it can draw at any single point in time or its ability todraw current continuously over time. This may be due to the fact thatthe locking system draws energy from batteries and with the intent ofbeing usable over a long period of time or because it is partiallypowered by an energy harvesting or trickle charge system.

The energy for the locking system may be stored by any type of energystorage technology (2800) which meets the physical constraints of thelocking system including but not limited to capacitive devices, variousbatteries of varying chemistries or mechanical energy storage.Appropriate circuitry associated with the energy storage technologywould ensure that potentially damaging erratic currents and voltageswould be brought to safe levels before being stored or utilized in therest of the locking system.

Power for the locking system may be generated and captured from therotation of a thumb-turn (2801) on the interior of the locking system ora similar locking system leverage point that rotates around a fixedspindle that may turn through a magnetic field to generate current(2804). Any number of mechanical interactions with the locking systemmay be used to capture energy which in turn would be used in the lockingsystem or stored in the energy storage technology (2800). These alsoinclude harvesting energy from vibrations (2802) to the locking systemthat may result from shutting or opening a component related to thelocking system. Power for the locking system may also be generated andcaptured from a photovoltaic or other light capture energy conversiondevice placed either on the interior or exterior of the device (2803).

FIG. 29 discloses in an example embodiment a number of methods by whicha locking system (2902) may lower its power consumption so as to extendbattery or energy storage lifetime. These methods include logic inherentto the locking system (2900) which would activate the most powerconsuming aspects of the locking system only at those points in timeduring the day when the locking system is likely to be used.

Such logic may be considered as an algorithm that considers the mostfrequent times of day that a locking system (2902) is used or has beenused in the past (2900). When it is calculated that there is anegligible or nil chance of an event being sent to the locking systemthe logic would disable the most power intensive components such asradios, microcontrollers, power regulators and other components. Thealgorithm may shift the schedule as the locking system logs access datafrom usage and passes this as a parameter into the algorithm. When thesystem periodically wakes up as determined by the algorithm it may checkfor lock, unlock or status commands send from the web service, and,potentially, from a mobile device proximate to the door or not, anotherthird-party web service, an application interface, web interface or textmessage interface.

A mobile device (2901) may generate certain radio signatures which aredetectable by specialized low-power consumption circuitry on the lockingsystem (2902). Examples of this include distinguishable signatures fromGSM™ (Global System for Mobile Communications), CDMA (Code-DivisionMultiple Access), Wi-Fi™, Bluetooth™ or other radio technologies whichare commonly available on mobile devices. The low-power consumptioncircuitry would not be intended to communicate directly with the radioson the mobile device, but instead would merely detect their existence soas to power up additional components such as microcontrollers, radiosand power regulators that would consume far more current when poweredon. The user would then be able to successfully send or receive data toor from the locking system, either directly or indirectly through a webservice, while the locking system would only need to consume significantamounts of power when a mobile device has been detected to be proximateto the locking system.

Other very low power consumption components in the locking system (2902)may be used to alert the system of the presence of a user so that otherhigh power consumption components may be activated at the proper time.Very low power components may include vibration sensors, passiveinfrared sensors, microphones or sensors external to the locking systemwhich communicate with the locking system over a very low power radiocomponent while high power radio components remain in a deep sleep orpowered down mode.

FIG. 30 discloses a locking system which has been modified toaccommodate the use of mobile devices and control through web serviceswhile still maintaining the original structure of access control. Thelocking system relies on commonly known and understood access controltechnologies that consist of a computer controller (3003) whichregulates whether or not passive radio credentials (3000) may lock,unlock, arm or disarm the locking or alarm system (3002) when scanned ata connected electronic credential reader (3001).

A traditional access control system may be modified so as to replace oraugment the existing electronic credential reader with a microcomputerwhich may communicate directly with a mobile device or with a webservice. The augmenting or replacement reading device (3001) may detector read from a data connection the information from the passiveelectronic credential. This data signature may be sent in an encryptedor unencrypted fashion as in the case with standards such as thecommonly used Wiegand technology. If encrypted, the device may usecommonly exposed or known private keys to decrypt the associated data.The device may act to replay the data so as to emulate the passive radiocredential. The emulation of the credential would be seamless to therest of the locking system and notably the original computer controller(3003).

In conjunction with the mobile device (3005) and associated web service(3004), users who already possess radio tokens for the original servicemay present their token at the newly augmented or replacement readerdevice (3001) so as to pair their credential with their user account.Once paired, the user from a mobile device may send a command such aslock or unlock through an application on the mobile device which in turnis relayed directly to the augmented reading device or indirectlythrough an associated web service. The augmenting reading device wouldreplay the associated radio token data to the original locking systemcontroller, emulating the user holding the original radio token next tothe reader.

Once paired, the user may send commands through the mobile interface,web interface, text-message interface or authenticated third-partyapplications. All of these commands would be ultimately executedaccording to the original access control computer system (3003),allowing the computer controller to maintain the exactly sameprogramming, logging and other capabilities present with the usage ofradio tokens. If the computer controller were to reject the emulatedtoken, this fact could be relayed to the web service or mobile userthrough a variety of methods.

By preserving the existing infrastructure, the new web service andmobile enabled infrastructure may easily and quickly installed whilemaintaining all programming related to the original computer controller.The web service (3004) may additionally communicate directly with thecomputer controller (3003) in order to bypass the need for augmentingthe reader component (3001). The augmented reader component may featureany range of proximity detection technology including those radios whichcommunicate directly with common mobile device radios like Bluetooth™,Wi-Fi™ or Near Field Communication.

Method Embodiments

Some embodiments of the present inventive subject matter include methodsof operating a remotely operable lock.

One such embodiment is illustrated in FIGS. 31-31G. In the exampleembodiment shown in FIG. 31, a method of operating a remotely operablelock comprises: at 3100, receiving credentials at a web service from aportable electronic device; at 3102, authenticating the credentials; andat 3104 based on a successful authentication, issuing a command forreceipt by the lock from the web service.

In FIG. 31, the method may at 3122 further comprise notifying a user ofthe closest geographically nearby operable lock to the device based onreceipt and authentication of the credentials, the geographically nearbyoperable lock being located within a determinable distance of thedevice. The method may further comprise at 3124 detecting proximity ofthe device to the lock.

In FIG. 31, the method of operating a remotely operable lock may furthercomprise, at 3152, controlling the lock in response to a command issuedby the web service or portable electronic device using a lock server incommunication with the web service or portable electronic device. InFIG. 31, the method may further comprise at 3166 using a remotelyoperable lock and notifying the user of successful actuation of the lockin response to the command.

In FIG. 31, the method may further comprise at 3190 providing a cameraassociated with the lock for taking a picture of a person seeking tooperate the lock. At 3192, the method may further comprise providing avibration sensor for detecting vibration of the lock or a doorassociated with the lock, and receiving a signal at least initiated bythe vibration sensor.

In FIG. 31, the method may further comprise at 3102A providing an onlineaccount at the web service for a user. In FIG. 31G, the method mayfurther comprise at 3104A providing a portal on the web service forentry by a user of credentials or a command for receipt by the lock.

In FIG. 31A, the receiving of the credentials at a web service from theportable electronic device 3100 may include at 3106 receiving devicecredentials relating to the portable electronic device. The devicecredentials may include at 3108 at least one device credential elementselected from a group comprising: GPS coordinates of the devicelocation; a Wi-Fi™ ID; a Bluetooth™ ID; a telephone number; SMS address;and pin code. The device credentials may at 3110 be cached in thedevice. The receiving of the credentials at a web service from theportable electronic device may include at 3112 receiving lockcredentials relating to the lock. At 3114, the lock credentials mayinclude at least one lock credential element selected from a groupcomprising: GPS coordinates of the lock or an identification tagassociated with the lock; Wi-Fi™ ID; Bluetooth™ ID; Near FieldCommunication verification; pin code entry; Quick Response (QR) coderecognition; and a timed lock operation. At 3116, at least some of thelock credentials may be cached in the portable electronic device. Thecached lock credentials may at 3118 allow at least partial authorizationof the credentials by the device. In FIG. 31B, authenticating thecredentials 3102 may include at 3120 at least some authentication of thecredentials being performed by the web service.

In FIG. 31A, the method may further comprise at 3198 receiving thecredentials from the portable electronic device as a text (SMS) message.In FIG. 31C, the method may further comprise at 3100A receiving acommand as a text (SMS) message from a user's portable electronic deviceand basing the command for receipt by the lock on the texted command.

In FIG. 31A, the method may further comprise at 3106A allowing the webservice to communicate with the portable electronic device using one ormore of the connectivity elements in a group comprising: Wi-Fi™; 3G/4G;EDGE (Enhanced Data rates for GSM Evolution), SMS (Short MessageService); and Ethernet. In FIG. 1, the method may further comprise at3108A notifying a user of an attempt or request to operate the lock. InFIG. 31B, the method may further comprise at 3110A authenticatingcredentials received from the user in response to the notification, andreceiving a command from the user to actuate the lock.

In FIG. 31B, the credentials may include at 3176 a unique codeassociated with a user of the portable electronic device. At 3178, afurther unique code may be associated with another user of the lock. At3180, authenticating the credentials may include use of one or more ofthe following elements in a group comprising: GPS coordinates; detectionof a Wi-Fi™ network; Near Field Communication verification; pin codeentry; Quick Response (QR) code recognition; and a timed entry.

In FIG. 31C, the command issued by the web service for receipt by thelock 3104 may be based at 3168 on an input received at the portableelectronic device from a user. At 3170, the command issued by the webservice for receipt by the lock may be based on input provided by theuser using a software application installed on the portable electronicdevice. At 3172, the command is one of the commands selected from agroup of commands comprising: lock; unlock; timed lock request; timedunlock request; and toggle lock/unlock request. At 3174, the command maybe associated with a customized lock operation scenario.

In FIG. 31C, the method may further comprise at 3182 providing a Wi-Fi™chip in the remotely operable lock for connectivity with a Wi-Fi™network, and issuing the command for receipt by the lock at least viathe Wi-Fi™ network. At 3184, Bluetooth™ connectivity may be provided forthe remotely operable lock, and the command for receipt by the lock isissued at least via a Bluetooth™ connection. At 3186, the method mayfurther allow pairing of the lock with a web-enabled portable electronicdevice, and issuing the command for receipt by the lock at least via aninternet connection established by the web-enabled portable electronicdevice. At 3188, the method may further comprise receiving thecredentials or a user command from the portable electronic device atleast via the internet connection.

In FIG. 31D, detecting the proximity of the device to the lock 3124 mayinclude at 3126 use of one or more of the following elements in a groupcomprising: reading a tag located proximately to and associated with thelock; GPS coordinates of the lock; GPS coordinates of the device;detection of a Wi-Fi™ or Bluetooth™ network; Near Field Communicationverification; pin code entry; Quick Response (QR) code recognition; and,a timed lock operation. At 3128, detecting of the proximity of thedevice to the lock may include comparing at least one credential elementcached in the device to a respective credential identified or receivedby the device. At 3130, detecting of the proximity of the device to thelock launches a software application on the device. At 3132, the methodfurther comprises providing a lock software application, associated withthe web service, for installation on the portable electronic device. At3134, the software application is to launch automatically in response todetecting proximity of the device to the lock. At 3136, the softwareapplication is further to notify the web service of the proximity of thedevice to the lock and the credentials upon launch.

In FIG. 31D, detecting the proximity of the device to the lock 3124 mayinclude at 3138 providing a tag located proximately to and associatedwith the lock. At 3140, the method may further comprise receiving asignal that the tag has been read by the portable electronic device. At3142, the tag may be a Near Field Communication (NFC) tag. At 3144, thetag may be encoded with a software application Universal ResourceIndicator (URI). At 3146, the automatic launch of the softwareapplication includes recognition by the portable electronic device ofthe Universal Resource Indicator (URI) encoded in the tag. At 3148, thetag may be encoded with a unique code, the unique code forming at leastpart of the credentials. At 3150, the credentials may be authenticatedby the web service using at least the unique code.

In FIG. 31E, placing the lock server in communication with the webservice may, at 3154, allow bidirectional communication between the lockserver and web service. At 3156, the method may further comprise sendingthe command to the lock using a wireless remote unit in communicationwith the lock server. At 3158, the method may further comprise sendingthe command to the lock using a relay control circuit in communicationwith the lock server. At 3160, the method may further comprise placingthe door lock server or lock in communication with the web service usinga user's internet service. At 3162, the method may further comprisenotifying a user that the lock server is not in communication with theweb service. At 3164, notifying of the user that the lock server is notin communication with the web service may occur in response to a failedreceipt by the lock of the command.

In FIG. 31F, the method may further comprise at 3194 notifying the userof the received signal initiated by the vibration sensor detectingvibration of the door or lock. Detecting vibration may at 3196 includedetecting a user's special knock on the lock or door associated with thelock, the special knock forming part of the credentials.

Another example method embodiment is illustrated in FIGS. 32-32G.

In the example embodiment shown in FIG. 32, a method of operating aremotely operable lock comprises: at 3200, authenticating, at a webservice, credentials received from a portable electronic device; at3202, detecting the proximity of the portable electronic device to thelock; and at 3204, issuing a command for receipt by the lock from theweb service or portable electronic device.

In FIG. 32, the method may further comprise at 3232 notifying a user ofa lock to select for operation, or the nearest operable lock, based onthe user's geo-location. The method may further comprise at 3238providing an application programming interface (API) for integratingthird party software with the web service to allow an associatedportable electronic device to operate the lock or communicate with theweb service.

In FIG. 32, the method may further comprise at 3262, allowing theremotely operable lock to connect to a Wi-Fi™ network, RF or radionetwork, or Bluetooth™ device, and issuing a command for receipt by thelock at least via the Wi-Fi™, RF or radio network, or Bluetooth™ device.At 3264, the method may further comprise allowing pairing of the lockwith a web-enabled portable electronic device, and issuing the commandfor receipt by the lock at least via an internet connection establishedby the web-enabled portable electronic device.

In FIG. 32, the method may further comprise at 3268 providing anaccessory component in association with the lock, the component tointegrate or communicate with the lock, the web service or a user to atleast assist in operating the lock. In FIG. 32, the method may furthercomprise at 3280 using a remotely operable lock and notifying a user ofsuccessful actuation of the lock in response to the command. The methodmay further comprise at 3290 notifying a first user of an attempt orrequest to operate the lock by a second user. At 3292, the method mayfurther comprise providing an online account at the web service for auser.

In FIG. 32A (i) the authenticating of the received credentials 3200 mayinclude at 3206 an initial authentication of the portable electronicdevice which allows the portable electronic device to communicatedirectly with the lock and issue a direct command for receipt by thelock. At 3208, at least some credentials may be cached in the portableelectronic device. At 3210, the cached credentials may allow at leastpartial authorization of the credentials by the device. At 3212, aremaining authentication of the credentials may be performed by the webservice. At 3214, the credentials may include at least one of thefollowing elements in a group comprising: GPS coordinates; detection ofa Wi-Fi™ network; Near Field Communication verification; pin code entry;Quick Response (QR) code recognition; and a timed entry. At 3216, thereceived credentials may include device credentials relating to theportable electronic device. At 3218, the received device credentials mayinclude at least one device credential element selected from a groupcomprising: GPS coordinates of the device location; a Wi-Fi™ ID; aBluetooth™ ID; a telephone number; SMS address; and pin code. At 3220,the received credentials may include lock credentials relating to thelock. At 3222, the lock credentials may include at least one lockcredential element selected from a group comprising: GPS coordinates ofthe lock or an identification tag associated with the lock; Wi-Fi™ ID;Bluetooth™ ID; Near Field Communication verification; pin code entry;Quick Response (QR) code recognition; and a timed lock operation.

In FIG. 32A (ii), the credentials may include at 3284 a unique codeassociated with a user of the portable electronic device. At 3286, themethod may further comprise issuing a further unique code associatedwith another user of the lock. At 3288, the method may further comprisereceiving the credentials from the portable electronic device as a text(SMS) message.

In FIG. 32B (i), detecting the proximity of the device to the lock 3202may include at 3224 use of one or more of the following elements in agroup comprising: reading a tag located proximately to and associatedwith the lock; GPS coordinates of the lock or device; detection of aWi-Fi™ or Bluetooth™ network; Near Field Communication verification; pincode entry; Quick Response (QR) code recognition; and, a timed lockoperation. At 3226, detecting the proximity of the device to the lockincludes comparing at least one credential element cached in the deviceto at least one respective credential identified by or received by thedevice. At 3228, detecting the proximity of the device to the lockfurther includes notifying a user of the identity of the lock. At 3230,notifying the user of the identity of the lock is based on receipt andauthentication of the received credentials.

In FIG. 32B (ii), detecting the proximity of the device to the lock 3202automatically launches at 3234 a software application installed on thedevice. At 3236, the software application may be a third partyapplication. At 3240, the command issued by the web service for receiptby the lock may be based on an input received at the portable electronicdevice from a user using the software application installed on thedevice. At 3242, the issued command may be one of the commands selectedfrom a group of commands comprising: lock; unlock; timed lock request;timed unlock request; and toggle lock/unlock request. At 3244, thesoftware application may be a lock software application, associated withthe web service, for installation on the portable electronic device. At3246, the software application may be further to notify the web serviceof the credentials upon launch.

In FIG. 32B (iii), detecting the proximity of the device to the lock3202 may include at 3248 providing a tag located proximately to andassociated with the lock, the tag to be read by the portable electronicdevice to launch the application. At 3250, the method may furthercomprise receiving a signal that the tag has been read by the portableelectronic device. At 3252, the tag may be a Near Field Communication(NFC) tag. At 3254, the tag may be encoded with a software applicationUniversal Resource Indicator (URI). At 3256, the launch of the softwareapplication includes recognition by the portable electronic device ofthe Universal Resource Indicator (URI) encoded in the tag. At 3258, thetag may be encoded with a unique code, the unique code forming at leastpart of the credentials. At 3260, the credentials may be authenticatedby the web service using at least the unique code.

In FIG. 32C, issuing a command 3204 may at 3282 include a commandassociated with a customized lock operation. The method may furthercomprise at 3296 receiving a command as a text (SMS) message from auser's portable electronic device and basing the command for receipt bythe lock on the texted command.

In FIG. 32D, allowing pairing 3264, further comprises at 3266 receivingor sending the credentials or a user command from the portableelectronic device at least via the internet connection.

In FIG. 32E, the accessory component may be at 3270 a component selectedfrom the group comprising: lock power component; lock operationcomponent; lock server; connectivity component; pin or command entrykeypad; presence detector; vibration sensor; doormat; doorbell; andvideo or still camera. At 3272, the connectivity component may be acomponent selected from the group of components comprising: Bluetooth™;Radio Frequency (RF); Wi-Fi™; internet; infrared; and piezo-electric. At3274, the accessory component may have a passive and an active state,and wherein detecting the proximity of the portable electronic device tothe lock triggers the accessory component into its active state, orcauses the component to perform an operation. At 3276, detecting theproximity of the portable electronic device to the lock may includenotifying a user that the accessory component is not in integration orcommunication with the lock or the web service. At 3278, notifying theuser that the component is not in integration or communication with thelock or web service occurs in response to a failed receipt by the lockof the command.

In FIG. 32F, the method may further comprise at 3294 authenticatingcredentials received from the first user in response to thenotification, and receiving a command from the first user to actuate thelock.

In FIG. 32G, the method may further comprise at 3298 providing a portalon the web service for entry by a user of credentials or a command forreceipt by the lock.

Another example method embodiment is illustrated in FIGS. 33-33C.

In the example embodiment shown in FIG. 33, a method of operating aremotely operable lock comprises: at 3300, providing a first web servicefor receiving credentials or a command from a portable electronic devicehaving a software application installed thereon; at 3302, issuing acommand for receipt by the lock from the web service; and at 3204,providing an application programming interface (API) at the first webservice for integrating a second web service or the software applicationwith the first web service to allow the portable electronic device tocommunicate with the lock or web service.

In FIG. 33A, the received credentials relating to a third party user orsecond web service may at 3322 be authenticated by an authenticated userof the lock. At 3324, the third party or second web service mayseamlessly issue a command to or receive data from the lock.

In FIG. 33A, the method may further comprise at 3310 authenticating thecredentials received at the web service, and based on a successfulauthentication, issuing the command for receipt by the lock. At 3312,the received credentials may relate to the lock. At 3314, the receivedcredentials may relate to the portable electronic device. At 3316, thereceived credentials may relate to a third party user or second webservice requesting access to the first web service or the lock.

In FIG. 33B, the command for receipt by the lock may at be received at3330 by the lock via the second web service.

In FIG. 33C, the software application may be at 3306 a third partysoftware application. At 3308, the integration is performed in responseto a request for access to the first web service or lock from a user.

In FIG. 33C, the command for receipt by the lock may be received at 3318by the lock via the second web service. At 3320, the integration isperformed in response to a request for access to the first web serviceor lock from an unauthenticated user.

In FIG. 33C, the third party application at 3326 automatically requestsaccess to the lock on behalf of a user based on the occurrence of anoutside event. At 3328, the outside event may be an event selected fromthe group comprising: booking a room for use at a certain time;requesting access to secure premises; delivery of a parcel; inspectionof premises; entry into a motor vehicle; and use of a bicycle.

These method embodiments are also referred to herein as “examples.” Suchexamples can include method elements in addition to those shown ordescribed. However, the present inventors also contemplate examples inwhich only those method elements shown or described are provided.Moreover, the present inventors also contemplate examples using anycombination or permutation of those method elements shown or describedabove (or one or more aspects thereof), either with respect to aparticular example (or one or more aspects thereof), or with respect toother examples (or one or more aspects thereof) shown or describedherein.

Processor Implementation

The various operations of example methods described herein may beperformed, at least partially, by one or more processors that aretemporarily configured (e.g., by software) or permanently configured toperform the relevant operations. Whether temporarily or permanentlyconfigured, such processors may constitute processor-implemented modulesthat operate to perform one or more operations or functions. The modulesreferred to herein may, in some example embodiments, compriseprocessor-implemented modules.

Similarly, the methods described herein may be at least partiallyprocessor-implemented. For example, at least some of the operations of amethod may be performed by one or more processors orprocessor-implemented modules. The performance of certain of theoperations may be distributed among the one or more processors, not onlyresiding within a single machine, but deployed across a number ofmachines. In some example embodiments, the processor or processors maybe located in a single location (e.g., within a home environment, anoffice environment, or as a server farm), while in other embodiments theprocessors may be distributed across a number of locations.

The one or more processors may also operate to support performance ofthe relevant operations in a “cloud computing” environment or as a“software as a service” (SaaS). For example, at least some of theoperations may be performed by a group of computers (as examples ofmachines including processors), with these operations being accessiblevia a network (e.g., the Internet) and via one or more appropriateinterfaces (e.g., APIs).

Electronic Apparatus And System

Example embodiments may be implemented in digital electronic circuitry,or in computer hardware, firmware, or software, or in combinations ofthem. Example embodiments may be implemented using a computer programproduct, e.g., a computer program tangibly embodied in an informationcarrier, e.g., in a machine-readable medium for execution by, or tocontrol the operation of, data processing apparatus, e.g., aprogrammable processor, a computer, or multiple computers.

A computer program can be written in any form of programming language,including compiled or interpreted languages, and it can be deployed inany form, including as a stand-alone program or as a module, subroutine,or other unit suitable for use in a computing environment. A computerprogram can be deployed to be executed on one computer or on multiplecomputers at one site or distributed across multiple sites andinterconnected by a communication network.

In example embodiments, operations may be performed by one or moreprogrammable processors executing a computer program to performfunctions by operating on input data and generating output. Methodoperations can also be performed by, and apparatus of exampleembodiments may be implemented as, special purpose logic circuitry(e.g., a FPGA or an ASIC).

The computing system can include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other. Inembodiments deploying a programmable computing system, it will beappreciated that both hardware and software architectures usuallyrequire consideration. Specifically, it will be appreciated that thechoice of whether to implement certain functionality in permanentlyconfigured hardware (e.g., an ASIC), in temporarily configured hardware(e.g., a combination of software and a programmable processor), or acombination of permanently and temporarily configured hardware may be adesign choice. Below are set out hardware (e.g., machine) and softwarearchitectures that may be deployed, in various example embodiments.

Example Machine Architecture and Machine-Readable Medium

FIG. 34 is a block diagram of machine in the example form of a computersystem 3400 within which instructions for causing the machine to performany one or more of the methodologies discussed herein may be executed.In alternative embodiments, the machine operates as a standalone deviceor may be connected (e.g., networked) to other machines. In a networkeddeployment, the machine may operate in the capacity of a server or aclient machine in server-client network environment, or as a peermachine in a peer-to-peer (or distributed) network environment. Themachine may be a personal computer (PC), a tablet PC, a set-top box(STB), a PDA, a cellular telephone, a web appliance, a network router,switch or bridge, or any machine capable of executing instructions(sequential or otherwise) that specify actions to be taken by thatmachine. Further, while only a single machine is illustrated, the term“machine” shall also be taken to include any collection of machines thatindividually or jointly execute a set (or multiple sets) of instructionsto perform any one or more of the methodologies discussed herein.

The example computer system 3400 includes a processor 3402 (e.g., acentral processing unit (CPU), a graphics processing unit (GPU) orboth), a main memory 3404 and a static memory 3406, which communicatewith each other via a bus 3408. The computer system 500 may furtherinclude a video display unit 3410 (e.g., a liquid crystal display (LCD)or a cathode ray tube (CRT)). The computer system 500 also includes analphanumeric input device 3412 (e.g., a keyboard), a user interface (UI)navigation or cursor control device 3414 (e.g., a mouse), a disk driveunit 3416, a signal generation device 3418 (e.g., a speaker) and anetwork interface device 3420.

Machine-Readable Medium

The disk drive unit 3416 includes a machine-readable medium 3422 onwhich is stored one or more sets of data structures and instructions3424 (e.g., software) embodying or utilized by any one or more of themethodologies or functions described herein. The instructions 3424 mayalso reside, completely or at least partially, within the main memory3404 and/or within the processor 3402 during execution thereof by thecomputer system 500, with the main memory 3404 and the processor 3402also constituting machine-readable media.

While the machine-readable medium 3422 is shown in an example embodimentto be a single medium, the term “machine-readable medium” may include asingle medium or multiple media (e.g., a centralized or distributeddatabase, and/or associated caches and servers) that store the one ormore data structures or instructions 3424. The term “machine-readablemedium” shall also be taken to include any tangible medium that iscapable of storing, encoding, or carrying instructions for execution bythe machine and that cause the machine to perform any one or more of themethodologies of the embodiments of the present invention, or that iscapable of storing, encoding or carrying data structures utilized by orassociated with such instructions. The term “machine-readable medium”shall accordingly be taken to include, but not be limited to,solid-state memories and optical and magnetic media. Specific examplesof machine-readable media include non-volatile memory, including by wayof example semiconductor memory devices (e.g., Erasable ProgrammableRead-Only Memory (EPROM), Electrically Erasable Programmable Read-OnlyMemory (EEPROM), and flash memory devices); magnetic disks such asinternal hard disks and removable disks; magneto-optical disks; andCD-ROM and DVD-ROM disks.

Transmission Medium

The instructions 3424 may further be transmitted or received over acommunications network 3426 using a transmission medium. Theinstructions 3424 may be transmitted using the network interface device3420 and any one of a number of well-known transfer protocols (e.g.,HTTP). Examples of communication networks include a LAN, a WAN, theInternet, mobile telephone networks, Plain Old Telephone (POTS)networks, and wireless data networks (e.g., Wi-Fi™ and WiMax™ networks).The term “transmission medium” shall be taken to include any intangiblemedium that is capable of storing, encoding or carrying instructions forexecution by the machine, and includes digital or analog communicationssignals or other intangible media to facilitate communication of suchsoftware.

Non-Limiting Embodiments

While the invention has been described with reference to specificembodiments, it will be understood by those skilled in the art thatvarious changes may be made and equivalents may be substituted for theelements thereof without departing from the true spirit and scope of theinvention. In addition, modifications may be made without departing fromthe essential teachings of the invention. Moreover, each of thenon-limiting examples described herein can stand on its own, or can becombined in various permutations or combinations with one or more of theother examples.

The above detailed description includes references to the accompanyingdrawings, which form a part of the detailed description. The drawingsshow, by way of illustration, specific embodiments in which theinvention can be practiced. These embodiments are also referred toherein as “examples.” Such examples can include elements in addition tothose shown or described. However, the present inventors alsocontemplate examples in which only those elements shown or described areprovided. Moreover, the present inventors also contemplate examplesusing any combination or permutation of those elements shown ordescribed (or one or more aspects thereof), either with respect to aparticular example (or one or more aspects thereof), or with respect toother examples (or one or more aspects thereof) shown or describedherein.

In the event of inconsistent usages between this document and anydocuments so incorporated by reference, the usage in this documentcontrols.

In this document, the terms “a” or “an” are used, as is common in patentdocuments, to include one or more than one, independent of any otherinstances or usages of “at least one” or “one or more.” In thisdocument, the term “or” is used to refer to a nonexclusive or, such that“A or B” includes “A but not B,” “B but not A,” and “A and B,” unlessotherwise indicated. In this document, the terms “including” and “inwhich” are used as the plain-English equivalents of the respective terms“comprising” and “wherein.” Also, in the following claims, the terms“including” and “comprising” are open-ended, that is, a system, device,article, composition, formulation, or process that includes elements inaddition to those listed after such a term in a claim are still deemedto fall within the scope of that claim. Moreover, in the followingclaims, the terms “first,” “second,” and “third,” etc. are used merelyas labels, and are not intended to impose numerical requirements ontheir objects.

Method examples described herein can be machine or computer-implementedat least in part. Some examples can include a computer-readable mediumor machine-readable medium encoded with instructions operable toconfigure an electronic device to perform methods as described in theabove examples. An implementation of such methods can include code, suchas microcode, assembly language code, a higher-level language code, orthe like. Such code can include computer readable instructions forperforming various methods. The code may form portions of computerprogram products. Further, in an example, the code can be tangiblystored on one or more volatile, non-transitory, or non-volatile tangiblecomputer-readable media, such as during execution or at other times.Examples of these tangible computer-readable media can include, but arenot limited to, hard disks, removable magnetic disks, removable opticaldisks (e.g., compact disks and digital video disks), magnetic cassettes,memory cards or sticks, random access memories (RAMs), read onlymemories (ROMs), and the like.

The above description is intended to be illustrative, and notrestrictive. For example, the above-described examples (or one or moreaspects thereof) may be used in combination with each other. Otherembodiments can be used, such as by one of ordinary skill in the artupon reviewing the above description. The Abstract is provided to complywith 37 C.F.R. §1.72(b), to allow the reader to quickly ascertain thenature of the technical disclosure. It is submitted with theunderstanding that it will not be used to interpret or limit the scopeor meaning of the claims. Also, in the above Detailed Description,various features may be grouped together to streamline the disclosure.This should not be interpreted as intending that an unclaimed disclosedfeature is essential to any claim. Rather, inventive subject matter maylie in less than all features of a particular disclosed embodiment.Thus, the following claims are hereby incorporated into the DetailedDescription as examples or embodiments, with each claim standing on itsown as a separate embodiment, and it is contemplated that suchembodiments can be combined with each other in various combinations orpermutations. The scope of the invention should be determined withreference to the appended claims, along with the full scope ofequivalents to which such claims are entitled.

1. A method of operating a remotely operable lock, the methodcomprising: providing a first web service for receiving credentials or acommand from a portable electronic device having a software applicationinstalled thereon; issuing a command for receipt by the lock from theweb service; and providing an application programming interface (API) atthe first web service for integrating a second web service or thesoftware application with the first web service to allow the portableelectronic device to communicate with the lock or web service.
 2. Themethod of claim 1, wherein the software application is a third partysoftware application.
 3. The method of claim 1, wherein the integrationis performed in response to a request for access to the first webservice or lock from a user.
 4. The method of claim 1, furthercomprising authenticating the credentials received at the web service,and based on a successful authentication, issuing the command forreceipt by the lock.
 5. The method of claim 1, wherein the receivedcredentials relate to the lock.
 6. The method of claim 1, wherein thereceived credentials relate to the portable electronic device.
 7. Themethod of claim 1, wherein the received credentials relate to a thirdparty user or second web service requesting access to the first webservice or the lock.
 8. The method of claim 1, wherein the command forreceipt by the lock is received by the lock via the second web service.9. The method of claim 4, wherein the integration is performed inresponse to a request for access to the first web service or lock froman unauthenticated user.
 10. The method of claim 7, wherein the receivedcredentials relating to a third party user or second web service areauthenticated by an authenticated user of the lock.
 11. The method ofclaim 10, wherein the third party or second web service may seamlesslyissue a command to or receive data from the lock.
 12. The method ofclaim 2, wherein the third party application automatically requestsaccess to the lock on behalf of a user based on the occurrence of anoutside event.
 13. The method of claim 12, wherein the outside event isan event selected from the group comprising: booking a room for use at acertain time; requesting access to secure premises; delivery of aparcel; inspection of premises; entry into a motor vehicle; and use of abicycle.
 14. A system for operating a remotely operable lock, the systemcomprising: a first web service to receive credentials or a command froma portable electronic device having a software application installedthereon, and to issue a command for receipt by the lock from the webservice; and the first web service having an application programminginterface (API) to integrate a second web service or the softwareapplication with the first web service to allow the portable electronicdevice to communicate with the lock or web service.